MUSKEL: an expandable skeleton environment

Programming models based on algorithmic skeletons promise to raise the level of abstraction perceived by programmers when implementing parallel applications, while guaranteeing good performance figures. At the same time, however, they restrict the freedom of programmers to implement arbitrary parallelism exploitation patterns. In fact, efficiency is achieved by restricting the parallelism exploitation patterns provided to the programmer to the useful ones for which efficient implementations, as well as useful and efficient compositions, are known. In this work we introduce muskel, a full Java library targeting workstation clusters, networks and grids and providing the programmers with a skeleton based parallel programming environment. muskel is implemented exploiting (macro) data flow technology, rather than the more usual skeleton technology relying on the use of implementation templates. Using data flow, muskel easily and efficiently implements both classical, predefined skeletons, and user-defined parallelism exploitation patterns. This provides a means to overcome some of the problems that Cole identified in his skeleton " manifesto " as the issues impairing skeleton success in the parallel programming arena. We discuss fully how user-defined skeletons are supported by exploiting a data flow implementation, experimental results and we also discuss extensions supporting the further characterization of skeletons with non-functional properties, such as security, through the use of Aspect Oriented Programming and annotations. 1. Introduction. Structured parallel programming models provide the user (programmer) with native high-level parallelism exploitation patterns that can be instantiated , possibly in a nested way, to implement a wide range of applications [13, 23, 24, 8, 6]. In particular, such programming models do not allow programmers to program parallel applications at the " assembly level " , i.e. by directly interacting with the distributed execution environment via communication or shared memory access primitives and/or via explicit scheduling and code mapping. Rather, the high-level native, parametric parallelism exploitation patterns provided encapsulate and abstract from these parallelism exploitation related details. For example, to implement an embarrassingly parallel application processing all the data items in an input stream or file, the programmer simply instantiates a " task farm " skeleton by providing the code necessary to process (sequentially) each input task item. The system, either a compiler and run time tool based implementation or a library based one, takes care of devising the appropriate distributed resources to be used, to schedule tasks on the resources and to distribute input tasks and gather output results according to the process mapping used. …